Skip to content

Conversation

@betulependule
Copy link

@betulependule betulependule commented Sep 22, 2025

Packit-service now supports the --package parameter in PR comments to specify package for which to run jobs. One test was added to test this functionality.

TODO:

  • Update or write new documentation in packit/packit.dev.

There is some commented monorepo-related code in process_fedora_ci_jobs. It's not used, but might be useful in future.

Fixes #2467

Related to

Merge before #1073

RELEASE NOTES BEGIN

Packit-service now supports the --package parameter in PR comments to specify package for which to run jobs.

RELEASE NOTES END

@sentry
Copy link

sentry bot commented Sep 22, 2025

🔍 Existing Issues For Review

Your pull request is modifying functions with the following pre-existing issues:

📄 File: packit_service/worker/jobs.py

Function Unhandled Issue
get_handlers_for_comment_and_rerun_event GitlabAPIException: 404: 404 Not found task.steve...
Event Count: 1

Did you find this useful? React with a 👍 or 👎

@softwarefactory-project-zuul
Copy link
Contributor

@betulependule betulependule marked this pull request as ready for review September 23, 2025 08:18
@betulependule betulependule requested a review from a team as a code owner September 23, 2025 08:18
@softwarefactory-project-zuul
Copy link
Contributor

@betulependule betulependule force-pushed the comment-monorepo-argument branch from d09f661 to 20aa8b5 Compare October 2, 2025 09:00
@softwarefactory-project-zuul
Copy link
Contributor

@betulependule betulependule force-pushed the comment-monorepo-argument branch from 3f4d48e to 9d9bb32 Compare October 2, 2025 10:00
@softwarefactory-project-zuul
Copy link
Contributor

@betulependule betulependule force-pushed the comment-monorepo-argument branch from 9d9bb32 to 8bf7bb0 Compare October 3, 2025 08:32
@softwarefactory-project-zuul
Copy link
Contributor

@softwarefactory-project-zuul
Copy link
Contributor

@betulependule betulependule force-pushed the comment-monorepo-argument branch from eb79df6 to 59420ee Compare October 3, 2025 09:02
@softwarefactory-project-zuul
Copy link
Contributor

Copy link
Member

@mfocko mfocko left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Overall LGTM, mostly formatting remarks… there's also one thing with the common options shared at the top-level, but I might be wrong there 👀

Comment on lines 113 to 115
parser.add_argument("--all-branches", action="store_true")
parser.add_argument("--with-pr-config", action="store_true")
parser.add_argument("--resolve-bug")
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Those aren't common for all Packit commands, are they? 👀

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think it's an issue… though the question is what should happen when you use an option that's not supported by some command, e.g., --resolve-bug is definitely not supported by /packit build

Probably error > silent-ignore, but not sure about it.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, they aren't common for all commands. I think it should be fixed in the later commits, where I made a subparser for each command, so that these arguments are defined only for the commands that support them.

args = parser.parse_args(commands)
return {"command": args.command, "monorepo_package": args.package}
except argparse.ArgumentError:
except SystemExit:
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Exit? 👀 that's from the argparse I presume?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, I was really surprised. I was expecting to get argparse.TypeError when the parser encountered an error, but the except argparse.TypeError clause got skipped when running tests and tests failed with SystemExit.

@softwarefactory-project-zuul
Copy link
Contributor

@softwarefactory-project-zuul
Copy link
Contributor

@betulependule betulependule requested a review from mfocko October 17, 2025 08:12
Copy link
Member

@mfocko mfocko left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, just one suggestion for a smaller improvement

@betulependule betulependule force-pushed the comment-monorepo-argument branch from 11026b5 to 769378a Compare November 5, 2025 08:55
@betulependule
Copy link
Author

/gemini review

Copy link
Contributor

@gemini-code-assist gemini-code-assist bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Code Review

This pull request introduces support for a --package parameter in PR comments to target specific packages in a monorepo, using argparse for comment parsing. The implementation is solid, but I have a few suggestions to improve code clarity, maintainability, and correctness. Specifically, I've pointed out an incorrect type hint and docstring, some dead code that can be removed, and an opportunity to refactor duplicated code.

Packit-service now supports the `--package` parameter
in PR comments to specify package for which to run jobs. One test
was added to test this functionality.
Comment parser has been split to two separate parsers: regular and
for Fedora CI. Each has its own defined arguments as per Packit
documentation.
By default, argparse seems to ignore newlines in the epilog string
used when generating help message, resulting in a messy help
message. RawTextHelpFormatter ensures the message (specifically,
the epilog part) is formatted properly. This going to be needed
when argparse is utilized by `/packit help` command in the future.
betulependule and others added 5 commits November 26, 2025 10:05
As per mfocko's suggestion, the parse_comment function now returns
an instance of ParsedComment rather than a dictionary to increase
the amount of code clarity. The parse_comment function now also
features a simple example in docstring.
Apply suggestions for cleaner code by removing unnecessary ternaries
and adjusting `ParsedComment` appropriately.

Co-authored-by: Matej Focko <[email protected]>
This function never returns `None`, so the type hint has been
edited to reflect this. The docstring has also been updated to
describe the correct return value.
@betulependule betulependule force-pushed the comment-monorepo-argument branch from 769378a to 108df99 Compare November 26, 2025 09:15
@softwarefactory-project-zuul
Copy link
Contributor

@betulependule
Copy link
Author

/gemini review

@softwarefactory-project-zuul
Copy link
Contributor

@betulependule
Copy link
Author

/gemini review

Copy link
Contributor

@gemini-code-assist gemini-code-assist bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Code Review

This pull request introduces support for triggering jobs for specific packages in a monorepo by adding a --package argument to PR comments. The implementation refactors command parsing to use Python's argparse module, which is a great improvement for robustness and maintainability. The changes are well-structured and include a new integration test for the feature.

I've found one issue with the filtering logic when --package is used on a non-monorepo project, which could lead to unintended job triggers. I've left a suggestion to correct this behavior. Overall, this is a solid contribution.

betulependule and others added 2 commits November 26, 2025 12:07
In previous implementation, using the `--package` parameter in a non-monorepo project would result in this parameter being ignored no matter the value given. With this new approach, using the `--package` parameter incorrectly in a non-monorepo project will result in all jobs being filtered out instead.

Co-authored-by: gemini-code-assist[bot] <176961590+gemini-code-assist[bot]@users.noreply.github.com>
@softwarefactory-project-zuul
Copy link
Contributor

@betulependule
Copy link
Author

recheck

@softwarefactory-project-zuul
Copy link
Contributor

@softwarefactory-project-zuul
Copy link
Contributor

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

Status: new

Development

Successfully merging this pull request may close these issues.

Trigger Packit only for specific monorepo

2 participants